В декабре прошлого года компания VMware анонсировала обновление решения VMware NSX-T 3.2, предназначенного для сетевой виртуализации и агрегации виртуальных сетей датацентров, работающих на базе гибридной среды гипервизоров, физических серверов и контейнеров приложений Kubernetes.

В новой версии этой платформы появились функции URL Filtering, позволяющие фильтровать доступ к веб-сайтам по их адресу на базе таких параметров, как категория URL, его репутация, а также различные кастомные правила. Сегодня мы приведем перевод статьи сайта Yo Go Virtual о том, как работать с этим механизмом.

URL filtering поддерживается только на шлюзе Tier-1 Gateway. Политика Access Control Policy для URL filtering применяется как к обычному http-трафику, так и для шифрованного https-канала, для которого нужно включить политику TLS Inspection, чтобы расшифровать трафик. Без включенного TLS inspection функция URL filtering будет использоваться на уровне домена с использованием расширения TLS Server Name Indication (SNI) в клиенте TLS hello. Эта возможность работает совместно с FQDN Analysis (которая ранее называлась URL Analysis в NSX-T 3.0).

Функция URL Filtering настраивается в профиле L7 access profile для правил сетевого экрана шлюза. Сначала мы включаем URL Database для кластера Edge Cluster, где мы хотим использовать эту возможность. Это вызовет скачивание базы данных URL из NSX Threat Intelligence Cloud Service.

Чтобы это сделать, идем в:

NSX Manager -> Security -> General Settings -> URL Database

Теперь надо создать L7 access profile, для чего идем в:

NSX Manager -> Inventory -> Profiles -> L7 Access Profiles

Нажимаем ADD L7 ACCESS PROFILE и вводим имя профиля:

Нажимаем Set в колонке создания одного или нескольких атрибутов Attribute Entries:

Нажимаем ADD ATTRIBUTE TYPE, где можно выбрать различные типы добавляемого атрибута...Читать статью далее->

Некоторые из вас, вероятно, знают такой сайт virten.net, где в свое время публиковалось много интересных технических статей об инфраструктуре VMware. Автор этого ресурса делает много интересных вещей, например, средство PowerShell OVF Helper.

OVF Helper - это репозиторий шаблонов для развертывания ВМ из виртуальных модулей (Virtual Appliances) в формате OVF, которые основаны на рабочем процессе развертывания в мастере создания машин vSphere Client. Через OVF Helper вы таким же образом соединяетесь с vCenter Server, заполняете нужные переменные и выполняете сценарий развертывания. Это точно так же просто, как и при использовании vSphere Client, но плюс в том, что вы можете использовать этот сценарий повторно, не проходя вручную шаги мастера клиента vSphere.

Также настроенные параметры в скрипте будут вам отличным напоминанием о том, какую конфигурацию вы использовали для виртуальных модулей.

На данный момент доступны сценарии для следующих продуктов и их версий:

• VMware NSX-T 3.2 | 3.1 | 3.0 | 2.5 | 2.4
• VMware NSX Advanced Load Balancer
• VMware NSX for vSphere 6.x
• VMware Cloud Director 10 | 10.2 | 10.3
• VMware vRealize Operations Manager 8.1
• VMware vRealize Orchestrator 8.1
• VMware vSphere Integrated Containers
• VMware ESXi Virtual Appliance
• VMware Photon OS 3.0 (cloud-init)
• VMware Event Broker Appliance 0.7

Также на странице PowerShell OVF Helper размещены ссылки на OVA-модули, которые рекомендуется использовать совместно с соответствующей версией сценария.

Кстати, обратите внимание на раздел Tools на сайте автора - там много чего интересного:

Компания VMware уже несколько недель назад сделала доступным каталог сессий предстоящего VMworld 2021. Некоторое время назад мы уже писали про изменения, которые произойдут в онлайн-конференции, а сегодня немного расскажем о самом каталоге будущих выступлений.

Сейчас в списке 850 сессий (может быть, будет больше), искать можно как по ключевым словам, так и по различным аспектам докладов (для кого они, о каких продуктах, уровень сложности материала и прочее).

А вот список самого интересного от Дункана Эппинга - глубокие технические сессии от известных блоггеров и сотрудников VMware:

• Project Monterey: Present, Future and Beyond [MCL1401] by Sudhanshu Jain and Simer Singh
  
• What Is the Future of Cloud and On-Premises Storage and Availability? [MCL2590]
• Make Sustainable Choices for Product Innovation, Operations: What Can I Do? [IC2794]
• Core Storage Best Practices Deep Dive [MCL2071]
  
• Security Deep Dive and Emerging Capabilities in VMware Cloud on AWS [SEC1362]
• VEBA Revolutions – Unleashing the Power of Event-Driven Automation [CODE2773]
• VDI Nerdfest 2021: Demos That Make Admins Drool [EUS1289]
  
• Extreme Performance Series: Performance best practices [MCL1635]
• 60 Minutes of Non-Uniform Memory Access (NUMA) 3rd Edition [MCL1853]
• Best Practices for Running AI Workloads in VMs on VMware vSphere [VI1459]
• The Future of VM Provisioning – Enabling VM Lifecycle Through Kubernetes [APP1564]
• The Evolution of Intelligent Edge and Electrical Grid Modernization [VI1455]
• Upskill Your Workforce with Augmented and Virtual Reality and VMware [VI1596]
• Automating Ransomware Remediation with the VMware Carbon Black Cloud SDK [CODE2782]
• Migration in Action with Google Cloud VMware Engine [MCL1764]

В общем, в начале октября будет точно что посмотреть и послушать!

Вильям Лам рассказал о том, как быстро и просто дать пользователям клиента VMware vSphere Client разрешения для просмотра пространств имен (namespaces) кластера vSphere with Tanzu.

Соответствующее разрешение нужно добавить в настройках Single Sign-On клиента:

Single Sign On->Users and Groups-> вкладка Groups

Находим там группу ServiceProviderUsers на второй странице и добавляем туда пользователей, которым мы хотим дать разрешение на просмотр неймспейсов:

После этого пользователю надо разлогиниться и залогиниться снова, а для просмотра пространств имен vSphere with Tanzu будет достаточно базовой роли Read Only для vSphere, которую можно дать разработчику (никаких изменений в конфигурацию чего бы то ни было такой пользователь внести не сможет):

Для пользователей и групп из Active Directory все работает точно таким же образом.

Некоторое время назад мы писали о First-Class Disks (FCD), которые были придуманы для того, чтобы управлять сервисами, заключенными в VMDK-диски, но не требующими виртуальных машин для своего постоянного существования.

Тома Persistent Volumes (PV) на платформе vSphere создаются как First-Class Disks (FCD). Это независимые диски без привязанных к ним ВМ. К таким относятся, например, тома VMware App Volumes, на которых размещаются приложения, и которые присоединяются к виртуальным машинам во время работы пользователя с основной машиной. Также к таким дискам относятся хранилища для cloud native приложений и приложений в контейнерах, например, работающих через Docker Plugin и драйвер Kubernetes.

При создании профиля хранилищ вы можете указать тип диска как FCD:

В VMware vSphere 7 Update 2 для FCD появилась поддержка снапшотов и их можно делать в количестве до 32 штук. Это позволяет делать снапшоты ваших K8s PV на платформе vSphere Tanzu.

В VMware vRealize Automation версии 8.2 появилась поддержка First-Class Disks (FCD), что открывает большие возможности по автоматизации операций при управлении такими хранилищами. Это функции улучшаются с каждым релизом vRA.

Eric Sloof написал небольшую заметку об использовании таких дисков с vRealize Automation. Одно из преимуществ дисков FCD - это возможность создавать их снапшоты независимо от каких-либо виртуальных машин.

При создании и редактировании описания профиля хранилищ в VMware vRealize Automation вы можете указать поддержку в дисков FCD или обычных дисков в storage profile:

Также через API в vRealize Automation вы можете получить доступ к операциям Create, Edit, Delete и List для таких дисков. Также в рамках рабочих процессов в Automation доступны и day-2 операции, такие как добавление диска, привязка/отвязывание и изменение размера.

Для снапшотов диска также доступны операции управления их жизненным циклом. Так что администраторы теперь могут придумывать и автоматизировать рабочие процессы с постоянными виртуальными дисками FCD для самых разных задач.

Недавно мы писали о VM Service - службе, которая дает разработчикам и администраторам, работающих со средой контейнеров Kubernetes в решении vSphere with Tanzu, возможности по развертыванию виртуальных машин. Она была анонсирована в vSphere 7 Update 2a. Также мы рассказывали о том, как зайти в консоль вспомогательных виртуальных машин VM Service.

Пару недель назад Cormac Hogan выпустил интересное видео для разработчиков и администраторов, в котором показывается, как можно создавать виртуальные машины на базе vSphere with Tanzu с помощью YAML-манифеста для пользовательских данных и ВМ:

Ну и, конечно же, рекомендуем отличную статью "A first look at vSphere VM Service" от автора видео.

Если у вас большая Enterprise-инсталляция VMware vSphere, и вам хочется оповещать пользователей о каких-либо важных статусах, изменениях или новостях, то вы можете использовать механизм Message of the Day (MotD) - сообщение, которое появляется в верхней части экрана vSphere Client. Например, пользователям можно сообщить, что они работают в Sandbox-окружении:

Вильям Лам рассказал о том, как правильно можно работать с этим с точки зрения автоматизации. В интерфейсе это сообщение можно настроить в разделе Configure->Settings->Message of Day:

Как видно из картинки выше, в этом сообщении поддерживаются специальные символы и эмоджи. Вот так это будет выглядеть для пользователей:

Ну и главное - как это автоматизировать, если у вас несколько окружений vCenter?

Вот такой командой можно получить сообщение дня через PowerCLI:

Get-AdvancedSetting -Entity $global:DefaultVIServer -Name vpxd.motd | select Value

К сожалению, с помощью Set-AdvancedSetting нельзя установить это сообщение, так как для обертки API это свойство находится в статусе Read Only. Поэтому нужно использовать API напрямую.

Вот так можно посмотреть текущий MotD:

$sm = Get-View $global:DefaultVIServer.ExtensionData.Content.SessionManager

$sm.Message

А вот так - обновить его:

$motd = "This is William Lam's environment, it is NOT supported. Use at your own risk"

$sm = Get-View $global:DefaultVIServer.ExtensionData.Content.SessionManager

$sm.UpdateServiceMessage($motd)

Некоторые администраторы VMware vSphere хотели бы закрыть доступ для некоторых пользователей к интерфейсу vSphere Client или ограничить его определенными адресами, оставив доступ через API. Например, это нужно тогда, когда пользователи vSphere не соблюдают установленные процедуры и регламенты при работе в интерфейсе клиента (например, не фиксируют внесенные в конфигурации виртуальных машин изменения).

Вильям Ламм рассказал о простом способе ограничения доступа к UI клиента vSphere Client. Делается это через настройки сервера Apache Tomcat, на базе которого построен виртуальный модуль vCenter Server Appliance. Называется это Access Control Valve - по ссылке можно подробно изучить опции, которые можно применять, а мы же рассмотрим простой пример ниже.

Идем по SSH на vCSA и открываем там следующий файл:

/usr/lib/vmware-vsphere-ui/server/conf/context.xml 

В него добавляем следующую запись:

<Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|localhost|x.x.x.x|y.y.y.y"/>

Значения x.x.x.x, y.y.y.y и далее за ними можно указать как разрешенные адреса для соединения с сервером. Блок "127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|localhost" должен присутствовать всегда для обеспечения локального соединения сервисов самого vCenter.

Адреса, не занесенные в этот список, при соединении через веб-браузер получат 403 ошибку, при этом доступ через PowerCLI и API останется для этих адресов (поскольку это только настройка веб-сервера):

Да, и надо не забыть, что для того, чтобы изменения веб-сервера вступили в силу, надо его перезапустить командой:

service-control --restart vsphere-ui

На сайте Вильяма Лама есть специальный раздел, посвященный вложенной виртуализации (Nested Virtualization) на базе гипервизора VMware ESXi. В частности, Вильям делает сборки ESXi, которые уже подготовлены к использованию в качестве виртуальных машин как виртуальные модули (Virtual Appliances) в формате OVA. Это может понадобиться для тестовых сред, когда вам нужно развернуть большую инфраструктуру и сделать полноценный кластер, а в распоряжении есть только 1-2 физических сервера.

Также обратите внимание на наш пост о библиотеке Content Library с шаблонами виртуальных модулей Nested ESXi от Вильяма. Адрес для подписки на эту библиотеку следующий:

https://download3.vmware.com/software/vmw-tools/lib.json

Кстати, все статьи о вложенной виртуализации можно найти и у нас по тегу Nested.

Дункан Эппинг написал интересный пост о том, что в кластере VMware HA есть возможность сделать хостам ESXi такую настройку, чтобы они выбирались как Primary при конфигурации/реконфигурации кластера. Это может оказаться полезным, например, в растянутом (Stretched) кластере, когда вам важно, чтобы Primary-хосты находились на основной площадке с целью ускорения процесса восстановления после сбоя (речь идет о 2-3 секундах в большинстве случаев, но для некоторых инфраструктур это может быть критично).

Пост этот актуален еще и потому, что настройки несколько изменились, начиная с VMware vSphere 7 Update 1, поэтому информация об этом может быть полезна для администраторов.

Прежде всего, в статье VMware KB 80594 рассказывается о том, какие настройки были изменены в механизме VMware FDM (он же HA). Самое главное, что до vCenter 7 Update 1 настройки хранились в файле /etc/opt/vmwware/fdm/fdm.cfg, теперь же они переехали в ConfigStore, работать с которым нужно путем импорта и экспорта json-файлов конфигурации.

Вот, кстати, интересующая нас табличка с изменениями параметров Advanced Settings в FDM:

Нас здесь интересует настройка node_goodness, большое численное значение которой и определяет, будет ли данный узел выбран как Primary (ранее в HA он также назывался Master).

Итак, Дункан показывает, как можно экспортировать расширенные настройки из ConfigStore:

configstorecli config current get -g cluster -c ha -k fdm
{
   "mem_reservation_MB": 200,
   "memory_checker_time_in_secs": 0
}

Все это можно также экспортировать в json-файл командой:

configstorecli config current get -g cluster -c ha -k fdm > test.json

Далее добавляем в этот json параметр node_goodness с большим значением, например, 10000000:

{
    "mem_reservation_MB": 200,
    "memory_checker_time_in_secs": 0,
    "node_goodness": 10000000
}

И импортируем его обратно в ConfigStore:

configstorecli config current set -g cluster -c ha -k fdm -infile test.json

В итоге хост ESXi 1507 был Primary:

А затем им стал узел 1505, для которого мы изменили данную расширенную настройку:

Ну и Дункан записал небольшое видео, раскрывающее весь процесс изменения данных настроек в VMware FDM / HA:

Наш постоянный читатель Сергей обратил внимание на то, что на днях компания VMware выпустила обновление своего главного фреймворка для управления виртуальной инфраструктурой с помощью сценариев - PowerCLI 12.2. Напомним, что о прошлой версии PowerCLI 12.1 осенью прошлого года мы писали вот тут.

Давайте посмотрим, что нового появилось в обновленном PowerCLI 12.2:

1. Поддержка VMware Horizon

Модуль PowerCLI для управления инфраструктурой Horizon теперь поддерживается для macOS и Linux OS.

2. Инфраструктура VMware Cloud

Появилась поддержка одного из самых популярных сервисов для обеспечения катастрофоустойчивости датацентров - DRaaS. Новые командлеты позволяют включать/отключать DRaaS в виртуальном датацентре VMC SDDC, а также добавлять и удалять инстансы SRM (Site Recovery Manager).

Вот так выглядит включение DRaaS:

Управление инстансами SRM происходит с помощью командлетов:

• Get-VmcSddcSiteRecoveryInstance
• New-VmcSddcSiteRecoveryInstance
• Remove-VmcSddcSiteRecoveryInstance

3. Поддержка VMware vSphere

• Расширенная поддержка vSphere Lifecycle Manager (vLCM)
  • Новые командлеты для экспорта и импорта состояния кластера
  • Новые командлеты для получения рекомендаций vLCM (Get-LcmClusterDesiredStateRecommendation)
  • Новые командлеты для получения аппаратной совместимости компонентов со стороны vLCM
  • Улучшенный командлет Set-Cluster для добавления кастомного репозитория ROBO-окружений
• Расширенная поддержка параметров OVF для объектов Content Library
• Добавлена поддержка шаблонов ВМ в Content Library
• Операция Foreach-object -Parallel теперь поддерживается

Вот так выглядит экспорт состояния кластера:

А вот так импорт:

4. Управление рабочими нагрузками

• Новые командлеты для управления лимитами пространств имен:
• Get-WMNamespaceLimits
• Set-WMNamespaceLimits

5. Поддержка NSX-T

• Теперь поддерживаются API компонента NSX-T global manager

Больше подробностей и примеров использования новых фич вы можете найти вот в этой статье. Скачать VMware PowerCLI 12.2 можно по этой ссылке.

Иногда администратор VMware vSphere задается вопросом о происхождении виртуальной машины - из какой родительской ВМ/шаблона она была клонирована? Вильям Лам разбирает это в своей статье, приведем вкратце его метод определения происхождения ВМ.

Как вы знаете, бывает три типа клонирования виртуальных машин в VMware vSphere:

• Full Clone - это полный клон, то есть независимая копия виртуальной машины, у которой нет ничего связанного с родительской ВМ, это просто ее полная копия.
• Linked Clone - это копия виртуальной машины, которая имеет общие диски с родительской, доступные на чтение (это экономит пространство и позволяет просто откатываться к родительскому образу). Уникальные данные эта машина хранит в собственных дельта-дисках.
• Instant Clone - это независимая копия виртуальной машины, которая начинает исполняться с какого-то момента и отделяется от основной машины. Для этого используются техники in-memory cloning и copy-on-write, которые используются также и для связанных клонов.

Чтобы найти источник клонированной машины, нужно проанализировать события vCenter Server Events. Вот какие они бывают касательно клонов:

• VmClonedEvent - появляется, когда происходит создание Full Clone или Linked Clone.
• com.vmware.vc.VmInstantClonedEvent - происходит при созданиии Instant Clone.
• VmDeployedEvent - вызывается, когда виртуальная машина развертывается из шаблона (vSphere Template или Content Library Template).

На базе анализа этих трех событий в истории vCenter Вильям Лам создал PowerCLI-функцию Get-VMCloneInfo, с помощью которой можно узнать родителя для виртуальной машины, если она была клонирована.

Устанавливаем ее простой командой:

Install-Script VMCloneInfo

На входе эта функция принимает имя ВМ, которую мы хотим проанализировать. Такой вывод мы получим, если машина не была клонирована:

> Get-VMCloneInfo -VMName "SourceVM"

Unable to find any cloning information for SourceVM, VM may not have been cloned or vCenter Events have rolled over

Так будет выглядеть вывод по полному клону:

> Get-VMCloneInfo -VMName "Full-Clone-VM"

  Type Source Date User

  ---- ------ ---- ----

Full SourceVM 1/3/2021 1:13:00 PM VSPHERE.LOCAL\Administrator

Так мы узнаем, что машина является связанным клоном:

> Get-VMCloneInfo -VMName "Linked-Clone-VM"

  Type Source Date User

  ---- ------ ---- ----

Linked SourceVM 1/3/2021 1:13:14 PM VSPHERE.LOCAL\Administrator

Так - что Instant-клоном:

> Get-VMCloneInfo -VMName "Instant-Clone-VM"

  Type Source Date User

  ---- ------ ---- ----

Instant SourceVM2 1/3/2021 1:12:44 PM VSPHERE.LOCAL\Administrator

Вот пример того, что машина была клонирована из шаблона vSphere Template:

> Get-VMCloneInfo -VMName "VMTX-VM"

  Type Source Date User

  ---- ------ ---- ----

Full SourceVMTXTemplate 1/3/2021 2:20:31 PM VSPHERE.LOCAL\Administrator

А вот - что из шаблона Content Library VM Template:

> Get-VMCloneInfo -VMName "VMTemplate-VM"

  Type Source Date User

  ---- ------ ---- ----

Full SourceVMTemplate 1/3/2021 2:23:41 PM VSPHERE.LOCAL\Administrator

На сайте virten.net, как обычно, вышла замечательная статья о реальной боли некоторых администраторов VMware vSphere - уменьшении дисков vCenter Server Appliance (vCSA). Так как vCSA работает в виртуальной машине, то иногда возникает необходимость в уменьшении ее дисков в целях простоты перемещения и компактности хранения. Но основная ситуация, когда диски vCSA чрезмерно разрастаются - это апгрейд сервера vCenter - в этом случае его хранилище может увеличиться до 1 ТБ при реально занятом пространстве в 100 ГБ. Тут уже без шринка (shrink) не обойтись.

При апгрейде vCSA установщик смотрит на аллоцированное пространство, а не на занятое, поэтому исходная машина в 416 ГБ может быть преобразована только в целевую ВМ типа Small с 480 ГБ диска:

Метод, описанный ниже, стоит применять только для виртуального модуля vCSA, который вы планируете апгрейдить, поскольку меняется порядок его дисков. Это, в целом, не проблема, но могут возникнуть сложности при взаимодействии с поддержкой VMware, которая может посчитать эту конфигурацию неприемлемой.

Перво-наперво нужно сделать бэкап вашего vCSA или его клон, с которым вы и будете работать. Если что-то не получится, вы просто сможете удалить клон.

Итак, заходим на vCSA по SSH и останавливаем все службы:

# service-control --stop --all

Выбираем файловую систему, для которой будем делать shrink. Например, /storage/seat имеет размер 296 ГБ, но реально используется 67 МБ! Запоминаем файловую систему (/dev/mapper/seat_vg-seat) и точку монтирования хранилища (/storage/seat), которое будем уменьшать.

Также из файловой системы вы можете получить Volume Group (seat_vg) и Logical Volume (seat):

# df -h
Filesystem                                Size  Used Avail Use% Mounted on
devtmpfs                                  4.9G     0  4.9G   0% /dev
tmpfs                                     4.9G  588K  4.9G   1% /dev/shm
tmpfs                                     4.9G  696K  4.9G   1% /run
tmpfs                                     4.9G     0  4.9G   0% /sys/fs/cgroup
/dev/sda3                                  11G  4.4G  5.7G  44% /
tmpfs                                     4.9G  1.6M  4.9G   1% /tmp
/dev/sda1                                 120M   34M   78M  31% /boot
/dev/mapper/core_vg-core                   25G   44M   24G   1% /storage/core
/dev/mapper/log_vg-log                    9.8G   72M  9.2G   1% /storage/log
/dev/mapper/db_vg-db                      9.8G  101M  9.1G   2% /storage/db
/dev/mapper/dblog_vg-dblog                 15G   86M   14G   1% /storage/dblog
/dev/mapper/seat_vg-seat                  296G   67M  283G   1% /storage/seat   <--- This is going to be shrinked
/dev/mapper/netdump_vg-netdump            985M  1.3M  916M   1% /storage/netdump
/dev/mapper/autodeploy_vg-autodeploy      9.8G   23M  9.2G   1% /storage/autodeploy
/dev/mapper/imagebuilder_vg-imagebuilder  9.8G   23M  9.2G   1% /storage/imagebuilder
/dev/mapper/updatemgr_vg-updatemgr         99G   75M   94G   1% /storage/updatemgr
/dev/mapper/archive_vg-archive             50G   64M   47G   1% /storage/archive

Размонтируем файловую систему:

# umount /storage/seat/

Проверяем ее:

# e2fsck -f /dev/mapper/seat_vg-seat

Теперь попробуем уменьшить размер этого раздела до 20 ГБ. У нас будет еще небольшой оверхед, поэтому сначала сожмем файловую систему до 18 ГБ:

resize2fs /dev/mapper/seat_vg-seat 18G

Теперь изменим логический том до чуть большего размера в 19 ГБ:

lvreduce -L 19G /dev/seat_vg/seat

Добавляем виртуальной машине диск в 20 ГБ:

Делаем рескан SCSI-шины:

# echo "- - -" > /sys/class/scsi_host/host2/scan

В данном случае используется хост-адаптер с ID=2. Для выяснения вашего ID используйте команду lsscsi. Не используйте скрипт rescan-scsi-bus.sh.

Запускаем dmesg для выяснения для идентификации созданного устройства (у нас это sdn):

# dmesg
[...]
[ 7649.086349] sd 2:0:14:0: Attached scsi generic sg17 type 0
[ 7649.087607] sd 2:0:14:0: [sdn] Attached SCSI disk

Инициализируем устройство для использования со стороны LVM:

# pvcreate /dev/sdn

Добавляем устройство в Volume Group, которую мы определили ранее (seat_vg):

# vgextend seat_vg /dev/sdn

Теперь у вас должно быть 2 устройства в группе seat_vg - sdh (старый большой диск) и sdn (новый уменьшенный):

# pvs |grep seat_vg
/dev/sdh seat_vg lvm2 a-- 299.99g 279.99g
/dev/sdn seat_vg lvm2 a-- 24.99g 24.99g

Перемещаем все физические экстенты с sdh на sdn:

# pvmove /dev/sdh /dev/sdn

Когда миграция будет закончена, sdh должен остаться пустым (Allocated PE = 0 и нет физических сегментов, только FREE):

# pvdisplay -m /dev/sdh
  --- Physical volume ---
  PV Name               /dev/sdh
  VG Name               seat_vg
  PV Size               300.00 GiB / not usable 7.00 MiB
  Allocatable           yes
  PE Size               8.00 MiB
  Total PE              38399
  Free PE               38399
  Allocated PE          0
  PV UUID               V7lkDg-Fxyr-qX4x-d3oi-KhNO-XZyT-EHgibI

  --- Physical Segments ---
  Physical extent 0 to 38398:
    FREE

Удаляем sdh из Volume Group:

# vgreduce seat_vg /dev/sdh

Удаляем LVM-метки из sdh:

# pvremove /dev/sdh

Запускаем скрипт autogrow.sh для расширения файловой системы к размеру виртуального диска:

/usr/lib/applmgmt/support/scripts/autogrow.sh

Последний шаг очень важен - удаляем старый диск. Не удалите не тот! Для этого проверяем SCSI ID с помощью lsscsi:

# lsscsi |grep sdh
[2:0:8:0] disk VMware Virtual disk 1.0 /dev/sdh

Мы видим, что SCSI ID [2:0:8:0] нам нужно удалить. Помните, что номер диска не всегда совпадает с SCSI ID. Удалите правильный диск (в данном случае 8), не ошибитесь!

Это все, теперь можно перезагрузить виртуальную машину, после чего в качестве опции апгрейда будет доступен вариант апгрейда на Tiny:

Если вы хотите уменьшить другие разделы, то идентифицируйте соответствующие параметры Logical Volume, Volume Group и Virtual Disk, после чего повторите процедуру.

Выясняем точки монтирования:

# df -h
Filesystem                                Size  Used Avail Use% Mounted on
devtmpfs                                  4.9G     0  4.9G   0% /dev
tmpfs                                     4.9G  588K  4.9G   1% /dev/shm
tmpfs                                     4.9G  696K  4.9G   1% /run
tmpfs                                     4.9G     0  4.9G   0% /sys/fs/cgroup
/dev/sda3                                  11G  4.4G  5.7G  44% /
tmpfs                                     4.9G  1.6M  4.9G   1% /tmp
/dev/sda1                                 120M   34M   78M  31% /boot
/dev/mapper/core_vg-core                   25G   44M   24G   1% /storage/core
/dev/mapper/log_vg-log                    9.8G   72M  9.2G   1% /storage/log
/dev/mapper/db_vg-db                      9.8G  101M  9.1G   2% /storage/db
/dev/mapper/dblog_vg-dblog                 15G   86M   14G   1% /storage/dblog
/dev/mapper/seat_vg-seat                  296G   67M  283G   1% /storage/seat
/dev/mapper/netdump_vg-netdump            985M  1.3M  916M   1% /storage/netdump
/dev/mapper/autodeploy_vg-autodeploy      9.8G   23M  9.2G   1% /storage/autodeploy
/dev/mapper/imagebuilder_vg-imagebuilder  9.8G   23M  9.2G   1% /storage/imagebuilder
/dev/mapper/updatemgr_vg-updatemgr         99G   75M   94G   1% /storage/updatemgr
/dev/mapper/archive_vg-archive             50G   64M   47G   1% /storage/archive

Выясняем SCSI ID и имя устройства:

# lsscsi
[0:0:0:0]    cd/dvd  NECVMWar VMware IDE CDR00 1.00  /dev/sr0
[2:0:0:0]    disk    VMware   Virtual disk     1.0   /dev/sda
[2:0:1:0]    disk    VMware   Virtual disk     1.0   /dev/sdb
[2:0:2:0]    disk    VMware   Virtual disk     1.0   /dev/sdc
[2:0:3:0]    disk    VMware   Virtual disk     1.0   /dev/sdd
[2:0:4:0]    disk    VMware   Virtual disk     1.0   /dev/sde
[2:0:5:0]    disk    VMware   Virtual disk     1.0   /dev/sdf
[2:0:6:0]    disk    VMware   Virtual disk     1.0   /dev/sdg
[2:0:8:0]    disk    VMware   Virtual disk     1.0   /dev/sdh
[2:0:9:0]    disk    VMware   Virtual disk     1.0   /dev/sdi
[2:0:10:0]   disk    VMware   Virtual disk     1.0   /dev/sdj
[2:0:11:0]   disk    VMware   Virtual disk     1.0   /dev/sdk
[2:0:12:0]   disk    VMware   Virtual disk     1.0   /dev/sdl
[2:0:13:0]   disk    VMware   Virtual disk     1.0   /dev/sdm

Выводим Logical Volumes:

# lvs
  LV           VG              Attr       LSize    Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  archive      archive_vg      -wi-ao----   49.99g
  autodeploy   autodeploy_vg   -wi-ao----    9.99g
  core         core_vg         -wi-ao----   24.99g
  db           db_vg           -wi-ao----    9.99g
  dblog        dblog_vg        -wi-ao----   14.99g
  imagebuilder imagebuilder_vg -wi-ao----    9.99g
  log          log_vg          -wi-ao----    9.99g
  netdump      netdump_vg      -wi-ao---- 1016.00m
  seat         seat_vg         -wi-ao----   20.00g
  swap1        swap_vg         -wi-ao----   24.99g
  updatemgr    updatemgr_vg    -wi-ao----   99.99g

Выводим Volume Groups:

# vgs
  VG              #PV #LV #SN Attr   VSize    VFree
  archive_vg        1   1   0 wz--n-   49.99g      0
  autodeploy_vg     1   1   0 wz--n-    9.99g      0
  core_vg           1   1   0 wz--n-   24.99g      0
  db_vg             1   1   0 wz--n-    9.99g      0
  dblog_vg          1   1   0 wz--n-   14.99g      0
  imagebuilder_vg   1   1   0 wz--n-    9.99g      0
  log_vg            1   1   0 wz--n-    9.99g      0
  netdump_vg        1   1   0 wz--n- 1016.00m      0
  seat_vg           1   1   0 wz--n-  299.99g 279.99g  <--- THIS
  swap_vg           1   1   0 wz--n-   24.99g      0
  updatemgr_vg      1   1   0 wz--n-   99.99g      0

Выводим диски и их Volume Group:

# pvs
  PV         VG              Fmt  Attr PSize    PFree
  /dev/sdc   swap_vg         lvm2 a--    24.99g      0
  /dev/sdd   core_vg         lvm2 a--    24.99g      0
  /dev/sde   log_vg          lvm2 a--     9.99g      0
  /dev/sdf   db_vg           lvm2 a--     9.99g      0
  /dev/sdg   dblog_vg        lvm2 a--    14.99g      0
  /dev/sdh   seat_vg         lvm2 a--   299.99g 279.99g
  /dev/sdi   netdump_vg      lvm2 a--  1016.00m      0
  /dev/sdj   autodeploy_vg   lvm2 a--     9.99g      0
  /dev/sdk   imagebuilder_vg lvm2 a--     9.99g      0
  /dev/sdl   updatemgr_vg    lvm2 a--    99.99g      0
  /dev/sdm   archive_vg      lvm2 a--    49.99g      0

Находим все диски в нашей Volume Group:

# pvs |grep seat_vg
  /dev/sdh   seat_vg         lvm2 a--   299.99g 279.99g
  /dev/sdn   seat_vg         lvm2 a--    24.99g  24.99g

Выводим информацию об LVM с точки зрения диска:

# pvdisplay -m /dev/sdh
  --- Physical volume ---
  PV Name               /dev/sdh
  VG Name               seat_vg
  PV Size               300.00 GiB / not usable 7.00 MiB
  Allocatable           yes
  PE Size               8.00 MiB
  Total PE              38399
  Free PE               35839
  Allocated PE          2560
  PV UUID               V7lkDg-Fxyr-qX4x-d3oi-KhNO-XZyT-EHgibI

  --- Physical Segments ---
  Physical extent 0 to 2559:
    Logical volume      /dev/seat_vg/seat
    Logical extents     0 to 2559
  Physical extent 2560 to 38398:
    FREE

Многие администраторы VMware vSAN задаются вопросом - а сколько прослужат диски в кластере хранилищ? Сегодня для vSAN уже имеет смысл использовать только SSD-диски, так как их стоимость уже вполне стала приемлемой для построения All-Flash хранилищ.

Как известно, в кластере vSAN есть 2 типа дисков - Cache (кэширование данных перед записью на постоянное хранение) и Capacity (постоянное хранилище). В первом случае, конечно же, использование ресурса диска идет в разы быстрее, чем для Capacity Tier.

Florian Grehl в своем блоге провел замер использования дисков обоих ярусов в плане записанных гигабайт в сутки в тестовой лаборатории. Вы сами сможете сделать это с помощью его PowerCLI-сценария, а также визуализовав данные в Graphite.

У него получилась вот такая картина:

В день у него получилось:

• 300 ГБ на диски Caching tier
• 20 ГБ на диски Capacity tier

Надо понимать, что объем записанных данных на каждый диск зависит от числа дисков в группе, а также развернутого типа RAID и политики FTT.

Когда вы покупаете SSD-диск, гарантия на него идет как на машину: время (обычно 5 лет), либо пробег (а в случае с диском это "TBW" = Terabytes Written, то есть записанный объем в ТБ) - в зависимости от того, что наступит раньше.

Как правило, для Capacity tier ресурс TBW за 5 лет на практике выработать не получится, а вот для Caching tier неплохо бы этот параметр замерить и сопоставить с характеристиками дисков. Например, 300 ГБ в день дает 535 ТБ за 5 лет.

Ну а вот параметры TBW, например, для устройств Samsung:

Как видно из таблицы, некоторые устройства могут прослужить вам значительно меньше 5 лет, в зависимости от интенсивности использования в вашей инфраструктуре и модели устройства.

Если вы хотели бы узнать, какие продукты есть у VMware, кроме тех, что у всех на слуху (вроде vSphere, vSAN и Horizon), то мы можем порекомендовать отличный документ - "VMware Product Guide". Там на ста страницах говорится обо всех продуктах, актуальных на декабрь 2020 года. Основная цель этого документа - рассказать об условиях использования и лицензирования, но из общей таблицы вы узнаете, что вообще есть в портфолио у VMware:

Ну а для тех, кто хочет увидеть весь список сразу со всеми ссылками на продукты, vCendra опубликовала вот такой интересный слайд от Ezzeldin Hussein, на котором можно увидеть все доступное на сегодня портфолио решений (кликабельно):

Скачать слайд в формате PPTX можно по этой ссылке.

Многие администраторы решения для создания отказоустойчивых хранилищ VMware vSAN иногда задумываются, чем отличаются политики хранилищ виртуальных машин (Storage Policies) для растянутых кластеров в плане Disaster Tolerance.

Дункан Эппинг написал об этом полезную заметку. Если вы не хотите, чтобы ваша виртуальная машина участвовала в растянутом кластере, то вам следует выбрать один из двух вариантов для настройки Site Disaster Tolerance: хранить все данные на основном сайте или все на резервном:

• None – Keep data on preferred (stretched cluster)
• None – Keep data on non-preferred (stretched cluster)

Между тем, в интерфейсе есть несколько схожих вариантов:

Например, есть еще два, казалось бы, подходящих:

• None – Stretched Cluster
• None – Standard Cluster

Но оба этих варианта политик хранилищ для растянутых кластеров не подходят. В первом случае (None – Stretched Cluster) виртуальная машина будет обрабатываться на уровне дисковых объектов, и vSAN будет решать, куда их поместить в растянутом кластере. Вполне может получиться такая ситуация, что один VMDK находится на одной площадке, а второй - на другой. При этом сама машина же может исполняться только на одном ESXi:

Такая ситуация очевидно очень плоха с точки зрения производительности.

Во втором же случае (None – Standard Cluster), если ваша машина настроена с точки зрения хранилищ на RAID-1 и FTT=1, то в растянутом кластере это превращается в SFTT=0 (Stretched FTT), что означает, что данные с одной площадки будут зеркалироваться на другую, но на уровне одной площадки будет храниться только одна копия данных дисковых объектов, что плохо с точки зрения надежности и отказоустойчивости.

Поэтому в растянутых кластерах для машин, которым не нужна "растянутость", используйте настройки Keep data on preferred или Keep data on non-preferred.

Решение для виртуализации сетей VMware NSX-T, в отличие от его vSphere-версии NSX-V, не имеет графического интерфейса для настройки отсылки логов на серверы Syslog.

Graham Smith написал краткую заметку о настройке Syslog для решения VMware NSX-T, включая NSX-T Manager, узлы Edge Nodes и серверы ESXi.

Самый удобный вариант - это использовать в качестве Syslog-сервера решение VMware Log Insight. Сначала заходим по SSH на NSX-T Manager и выполняем там следующую команду, указав IP-адрес сервера Log Insight:

MulNSXT01> set logging-server 192.168.10.8 proto udp level info 
        WARNING - You are configuring udp-based log forwarding. This will send sensitive information unencrypted over the network. The Splunk App for NSX-T only accepts TLS connections.

На узлах Edge Nodes также нужно выполнить такую же команду, зайдя по SSH:

DCA-MulNSXT-ESG01> set logging-server 192.168.10.8 proto udp level info
        WARNING - You are configuring udp-based log forwarding. This will send sensitive information unencrypted over the network. The Splunk App for NSX-T only accepts TLS connections.

На серверах ESXi процесс выглядит несколько иначе. Нужно выполнить вот такую последовательность команд:

[root@DCA-MulComp01:~] esxcli network firewall ruleset set -r syslog -e true
[root@DCA-MulComp01:~] esxcli system syslog config set --loghost=udp://192.168.10.8:514
[root@DCA-MulComp01:~] esxcli system syslog reload
[root@DCA-MulComp01:~] esxcli system syslog mark -s "This is a test message"

Первая команда разрешает в фаерволе трафик Syslog, вторая - настраивает сервер адрес сервера, третья - подхватывает настройки, ну а четвертая - отсылает тестовое сообщение, чтобы можно было проверить работоспособность механизма Syslog со стороны Log Insight.

Там это тестовое сообщение можно увидеть в разделе Events:

Чтобы проверить логирование на стороне фаервола, можно создать простое правило с тестовым тэгом:

Далее в Log Insight можно увидеть это событие, поискав по этому тегу:

Чтобы проверить конфигурацию Syslog на стороне сервера ESXi, нужно выполнить следующую команду:

[root@DCA-MulComp01:~] esxcli system syslog config get
   Check Certificate Revocation: false
   Default Network Retry Timeout: 180
   Dropped Log File Rotation Size: 100
   Dropped Log File Rotations: 10
   Enforce SSLCertificates: true
   Local Log Output: /scratch/log
   Local Log Output Is Configured: false
   Local Log Output Is Persistent: true
   Local Logging Default Rotation Size: 1024
   Local Logging Default Rotations: 8
   Log To Unique Subdirectory: false
   Message Queue Drop Mark: 90
   Remote Host: udp://192.168.10.8:514
   Strict X509Compliance: false

На стороне NSX-T Manager и на узлах Edge Nodes конфигурацию Syslog можно проверить такой командой:

DCA-MulNSXT-ESG01> get logging-servers 
Mon Dec 28 2020 UTC 17:37:16.600
192.168.10.8:514 proto udp level info

В прошлом году мы писали о полезной утилите VMware Configuration Maximums Tool, которая позволяет выводить максимальные конфигурации для различных продуктов VMware. Эта очень полезная штука для администраторов vSphere умеет не только выводить список всех максимумов, но и сравнивать их для разных версий одного продукта.

Для этого нужно выбрать пункт меню "Compare Limits" и указать сравниваемые версии продуктов:

Штука эта очень удобная, но у нее есть большой недостаток - она выводит все конфигурации максимумов (для NSX-T, например, их 274 штуки, поэтому сложно отследить, что именно изменилось).

Поэтому Dale Coghlan написал интересный PowerCLI-модуль VMware.CfgMax, который решает эту проблему - в режиме командной строки можно узнать об изменениях максимумов, а также сделать еще несколько полезных вещей.

После установки модуля можно вывести список доступных продуктов, которые есть на configmax.vmware.com:

Для конкретного продукта можно вывести список его версий/релизов:

Также для конкретной версии можно вывести список категорий максимумов:

С помощью командлета можно вывести все максимумы для конкретного продукта и определенной его версии:

Можно вывести все конфигурации в рамках заданной категории:

Ну и, наконец, с помощью командлета Compare-CfgMaxLimits можно сравнить максимумы конфигураций для разных версий одного продукта:

Как вы видите, тут есть поле CompareStatus, которое и говорит нам, новая ли эта настройка (New), измененная по сравнению с прошлым релизом (Modified), нетронутая (пусто) или удаленная (Deleted) в новой версии.

С помощью параметра New можно, например, вывести все новые настройки:

Параметр Modified выведет только отличающиеся максимумы конфигураций:

Ну а параметр Deleted выведет устаревшие настройки:

Ну и все вместе, без неизмененных значений:

Очень удобная штука, все это также можно экспортировать в формат CSV и сравнивать в Excel. Для этого можно использовать следующую команду:

PS > $product = Get-CfgMaxProduct -Name 'NSX-T Data Center'
PS > $releaseA =  $product | Get-CfgMaxRelease -Version 'NSX-T Data Center 3.0.0'
PS > $releaseB =  $product | Get-CfgMaxRelease -Version 'NSX-T Data Center 3.1.0'
PS > Compare-CfgMaxLimits -Product $product -Release $releaseA -CompareRelease $releaseB | Export-Csv -Path compare-status.csv -NoTypeInformation

Скачать данный PowerCLI сценарий с примерами вы можете по этой ссылке.

На сайте virten.net (клевый, кстати, ресурс) появилось описание серьезной ошибки файловой системы VMware VMFS 6, которая используется для создания датасторов в ESXi 7.0 (Build 15843807) и 7.0b (Build 16324942). Он касается кучи ФС (VMFS heap), которая переполняется из-за некорректной работы механизма ее очистки. В VMware vSphere 7 Update 1 эта ситуация решена. Сама проблема описана в KB 80188.

Симптомы переполнения кучи, как правило, следующие:

• Датасторы на хостах показывают статус "Not consumed"
• Виртуальные машины не могут выполнить vMotion
• Виртуальные машины "сиротеют" (переходят в статус "orphaned") при выключении
• При создании снапшота возникает ошибка "An error occurred while saving the snapshot: Error."

В логе vmkernel.log могут появляться следующие сообщения об ошибках:

• Heap vmfs3 already at its maximum size. Cannot expand
• Heap vmfs3: Maximum allowed growth (#) too small for size (#)
• Failed to initialize VMFS distributed locking on volume #: Out of memory
• Failed to get object 28 type 1 uuid # FD 0 gen 0: Out of memory

Память для кучи VMFS принудительно очищается при аллокации ресурсов файловой системы, например, обычных thick-дисков. Поэтому воркэраунд получается следующий - нужно создать диск Eager zeroed thick на всех смонтированных к хостам ESXi датасторах. Делается это командой:

# vmkfstools -c 10M -d eagerzeroedthick /vmfs/volumes/datastore/eztDisk

Удалить этот диск можно командой:

# vmkfstools -U /vmfs/volumes/datastore/eztDisk

Проблема только в том, что нужно выполнить эту операцию на каждом датасторе каждого хоста. Поэтому есть вот такая команда для всех датасторов и хостов:

# for I in $(esxcli storage filesystem list |grep 'VMFS-6' |awk '{print $1}'); do vmkfstools -c 10M -d eagerzeroedthick $I/eztDisk;echo "Removing disk $I/eztDisk"; vmkfstools -U $I/eztDisk; done

Результат будет примерно таким:

Сейчас какого-то отдельного патча для решения этой проблемы нет, поэтому нужно самостоятельно следить за поведением инфраструктуры. Основным симптомом является появление в vmkernel.log следующего сообщения:

Maximum allowed growth * too small for size

Если у вас есть такой продукт, как VMware Log Insight, то вы можете настроить аларм на появление этого сообщения в логе.

Коллега с virten.net написал замечательную статью об использовании сетевых адаптеров USB на хостах VMware ESXi, основные моменты которой мы приведем ниже.

Напомним, что подключить сетевые адаптеры USB на хостах ESXi можно с помощью драйвера USB Network Native Driver for ESXi, о котором мы не так давно писали вот тут. Такой адаптер, например, можно использовать, когда вам необходимо подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов.

Еще один вариант использования таких адаптеров - когда у вас (например, на тестовом сервере) есть всего один гигабитный порт, а вам нужно тестировать технологии и продукты, где нужно несколько высокоскоростных соединений.

Итак, после того, как вы скачаете драйвер, его установка делается одной командой:

# esxcli software vib install -d /path/ESXi700-VMKUSB-NIC-FLING-39035884-component-16770668.zip

На VMware ESXi 7 можно использовать фичу "component":

# esxcli software component apply -d /path/ESXi700-VMKUSB-NIC-FLING-39035884-component-16770668.zip

С помощью PowerShell можно создать кастомизированный образ ESXi с уже вшитым драйвером сетевого USB-адаптера. Просто раскомментируйте строчку с нужной версией драйвера:

# ESXi 7.0 Image with USB NIC Fling 1.6:
$baseProfile = "ESXi-7.0.0-15843807-standard"   # See https://www.virten.net/vmware/vmware-esxi-image-profiles/ for available Image Profiles

$usbFling = "ESXi700-VMKUSB-NIC-FLING-39035884-component-16770668.zip"        # Uncomment for ESXi 7.0

#$usbFling = "ESXi670-VMKUSB-NIC-FLING-39203948-offline_bundle-16780994.zip"  # Uncomment for ESXi 6.7

#$usbFling = "ESXi650-VMKUSB-NIC-FLING-39176435-offline_bundle-16775917.zip"  # Uncomment for ESXi 6.5
Add-EsxSoftwareDepot https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

Export-ESXImageProfile -ImageProfile $baseProfile -ExportToBundle -filepath "$($baseProfile).zip"

Remove-EsxSoftwareDepot https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

Invoke-WebRequest -Method "GET" https://download3.vmware.com/software/vmw-tools/USBNND/$($usbFling) -OutFile $($usbFling)

Add-EsxSoftwareDepot "$($baseProfile).zip"

Add-EsxSoftwareDepot $usbFling

$newProfile = New-EsxImageProfile -CloneProfile $baseProfile -name $($baseProfile.Replace("standard", "usbnic")) -Vendor "virten.net"

Add-EsxSoftwarePackage -ImageProfile $newProfile -SoftwarePackage "vmkusb-nic-fling"

Export-ESXImageProfile -ImageProfile $newProfile -ExportToIso -filepath "$($baseProfile.Replace("standard", "usbnic")).iso"

Export-ESXImageProfile -ImageProfile $newProfile -ExportToBundle -filepath "$($baseProfile.Replace("standard", "usbnic")).zip"
 

При установке VMware ESXi на хост, где есть только USB сетевые адаптеры, процесс может зависнуть на 81%. В этом случае почитайте вот эту статью.

Кстати, ваши USB-адаптеры лучше всего пометить наклейками. Автор предлагает указать имя хоста ESXi, MAC-адрес адаптера и его номер vusbX:

Номер виртуального vusbX не сохраняется при перезагрузках. Начиная с версии драйвера 1.6 можно закрепить MAC-адрес за нужным vusbX. Сначала найдем наш адаптер:

# esxcli network nic list |grep vusb |awk '{print $1, $8}'

vusb0 00:23:54:8c:43:45

vusb1 a0:ce:c8:cd:3d:5d

Затем сделаем статический маппинг адаптеров с использованием модуля vmkusb_nic_fling:

# esxcli system module parameters set -p "vusb0_mac=00:23:54:8c:43:45 vusb1_mac=a0:ce:c8:cd:3d:5d" -m vmkusb_nic_fling

В данной команде нужно перечислить все адаптеры через пробел (если вы вызываете ее второй раз, то нужно переуказать каждый из адаптеров, иначе маппинг сбросится).

Далее нужно проверить маппинги с помощью команды:

# esxcli system module parameters list -m vmkusb_nic_fling
Name                        Type    Value              Description
--------------------------  ------  -----------------  -----------
usbCdromPassthroughEnabled  int                        Enable USB CDROM device for USB passtrough: 0 No, 1 Yes
vusb0_mac                   string  00:23:54:8c:43:45  persist vusb0 MAC Address: xx:xx:xx:xx:xx:xx
vusb1_mac                   string  a0:ce:c8:cd:3d:5d  persist vusb1 MAC Address: xx:xx:xx:xx:xx:xx
vusb2_mac                   string                     persist vusb2 MAC Address: xx:xx:xx:xx:xx:xx
vusb3_mac                   string                     persist vusb3 MAC Address: xx:xx:xx:xx:xx:xx
vusb4_mac                   string                     persist vusb4 MAC Address: xx:xx:xx:xx:xx:xx
vusb5_mac                   string                     persist vusb5 MAC Address: xx:xx:xx:xx:xx:xx
vusb6_mac                   string                     persist vusb6 MAC Address: xx:xx:xx:xx:xx:xx
vusb7_mac                   string                     persist vusb7 MAC Address: xx:xx:xx:xx:xx:xx

Если вы хотите сделать текущий маппинг постоянным, то используйте команду:

# esxcli system module parameters set -p "$(esxcli network nic list |grep vusb |awk '{print $1 "_mac=" $8}' | awk 1 ORS=' ')" -m vmkusb_nic_fling

Также статические маппинги можно сделать и через PowerCLI. Выводим адаптеры:

PS> Get-VMHostNetworkAdapter -VMHost esx2.virten.lab -Physical -Name vusb* |select Name,Mac 

Name  Mac

----  ---

vusb0 00:23:54:8c:43:45

vusb1 a0:ce:c8:cd:3d:5d

Настраиваем маппинги MAC-адресов:

PS> get-vmhost esx2.virten.lab | Get-VMHostModule vmkusb_nic_fling | Set-VMHostModule -Options "vusb0_mac=00:23:54:8c:43:45 vusb1_mac=a0:ce:c8:cd:3d:5d"
 

Проверяем результат:

PS> get-vmhost esx2.virten.lab | Get-VMHostModule vmkusb_nic_fling |ft -AutoSize

  Name             Options

  ----             -------

vmkusb_nic_fling vusb0_mac=00:23:54:8c:43:45 vusb1_mac=a0:ce:c8:cd:3d:5d

Тестируем производительность адаптеров

В тесте используются три типа адаптеров на хосте ESXi:

• Intel NUC embedded NIC (подключен к физическому коммутатору)
• 1 Gbit StarTech USB NIC (подключен к физическому коммутатору)
• 2.5 Gbit CableCreation (кросс-соединение между хостами)

Измеряем задержки (latency) с помощью пинга (50 штук):

# ping [Address] -c 50

Результат:

Далее тестируем пропускную способность (bandwidth) с помощью iperf3. Для этого нужно сделать копию бинарника утилиты:

# cp /usr/lib/vmware/vsan/bin/iperf3 /usr/lib/vmware/vsan/bin/iperf3.copy

Запускаем сервер на первом ESXi:

# /usr/lib/vmware/vsan/bin/iperf3.copy -s

Далее запускаем клиент на втором ESXi. Тест идет 5 минут (300 секунд) с сэмплами каждые 10 секунд:

# /usr/lib/vmware/vsan/bin/iperf3.copy -i 10 -t 300 -c [SERVER-IP]

Результат:

Далее проводим операцию vMotion виртуальной машины между хостами ESXi. Результат таков:

Очевидно, кросс-соединение на адаптерах 2.5G рулит.

Проверка совместимости

Не все сетевые адаптеры USB поддерживаются нативным драйвером. Их актуальный список всегда можно найти вот тут. Вот эти адаптеры точно работают:

Адаптеры доступны в форм-факторах USB-A и USB-C. Между ними есть переходники.

Если вам нужно высокоскоростное соединение (multi-gigabit) между несколькими хостами, можно посмотреть на следующие коммутаторы:

• MikroTik CRS305-1G-4S+IN ($130 USD) - 4 порта
• MikroTik CRS309-1G-8S+IN ($260 USD) - 8 портов
• Netgear MS510TX ($260 USD) - 10 портов
• TRENDnet TEG-30102WS ($450 USD) - 10 портов

Самое быстрое и дешевое соединение между двумя хостами ESXi - соединить адаптеры патч-кордом напрямую:

Проверяйте параметр MTU size, когда включаете Jumbo Frames

Если вы меняете размер MTU на виртуальном коммутаторе, он принудительно меняется на всех подключенных к нему физических сетевых адаптерах. Имейте в виду, что эти адаптеры должны поддерживать выставляемый MTU size.

Посмотреть размер MTU можно следующей командой:

[root@esx4:~] esxcfg-nics -l
Name    PCI          Driver      Link Speed      Duplex MAC Address       MTU    Description
vmnic0  0000:00:1f.6 ne1000      Up   1000Mbps   Full   00:1f:c6:9c:47:13 1500   Intel Corporation Ethernet Connection (2) I219-LM
vusb0   Pseudo       uether      Up   1000Mbps   Full   00:24:9b:1a:bd:18 1600   ASIX Elec. Corp. AX88179
vusb1   Pseudo       uether      Up   1000Mbps   Full   00:24:9b:1a:bd:19 1500   ASIX Elec. Corp. AX88179

В данном примере MTU size настроен как 1600, что подходит для адаптеров (и работает для сети NSX-T). Если же вы поставите его в 9000, то увидите в vmkernel.log ошибки для dvSwitch о том, что такой размер не поддерживается устройством:

2020-07-19T16:10:42.344Z cpu6:524356)WARNING: vmkusb: Set MTU 9000 is not supported: Failure
2020-07-19T16:10:42.344Z cpu6:524356)WARNING: Uplink: 16632: Failed to set MTU to 9000 on vusb0

Если вы хотите проверить корректность вашего MTU size, то можно использовать команду ping с размером пакета MTU-28 байт (8 байт на заголовок ICMP и 20 байт на заголовок IP). Таким образом, для MTU size 1600 используйте число 1572:

[root@esx2:~] vmkping ++netstack=vxlan 192.168.225.10 -d -s 1572 -I vmk10
PING 192.168.225.10 (192.168.225.10): 1572 data bytes
1580 bytes from 192.168.225.10: icmp_seq=0 ttl=64 time=0.680 ms

[root@esx2:~] vmkping ++netstack=vxlan 192.168.225.10 -d -s 1573 -I vmk10
PING 192.168.225.10 (192.168.225.10): 1573 data bytes
sendto() failed (Message too long)

Источник статьи.

Возможно, некоторые администраторы VMware vSphere попадали в ситуацию, когда один из датасторов в виртуальной инфраструктуре оказывался не привязанным ни к какому хосту ESXi, но при этом у него также была неактивна опция Delete Datastore из контекстного меню:

Paul Braren написал полезную инструкцию у себя в блоге о том, как решить эту проблему.

Такой зомби-датастор можно удалить только из базы данных vCenter Server Appliance (vCSA), поэтому вы полностью должны быть уверены в том, что он не используется никаким из хостов, а также в том, что он не презентует никакое физическое устройство в вашей инфраструктуре.

Первое что вам надо сделать - это включить доступ к vCSA по SSH (картинки - отсюда):

Далее нужно зайти по SSH на vCSA, запустить там шелл командой shell и далее запустить утилиту psql для работы с базой данных следующей командой:

/opt/vmware/vpostgres/current/bin/psql -d VCDB -U postgres

После этого нужно найти id датастора следующей командой:

Когда вы нашли id, нужно удалить упоминание об этом датасторе из таблиц базы данных vCSA следующими командами:

DELETE FROM vpx_ds_assignment WHERE ds_id=3089;
DELETE FROM vpx_datastore WHERE id=3089;
DELETE FROM vpx_vm_ds_space WHERE ds_id=3089;

При выполнении второй операции вы получите следующую ошибку:

ERROR: update or delete on table "vpx_datastore" violates foreign key constraing "fk_vpxspace"
DETAIL: Key (id)=(3089) is still referenced from table "vpx_vm_ds_space".

Не обращайте на нее внимания и выполняйте третью. Затем нужно перезагрузить vCSA и снова выполнить второй DELETE, который в этот раз должен завершиться успешно. После этого датастор пропадет из списка в vSphere Client.

Помните, что выполняя данную операцию, вы должны понимать, что именно делаете:)

Многие администраторы платформы VMware vSphere после выхода седьмой версии продукта обнаружили, что ESXi 7.0 больше не хочет устанавливаться на старом оборудовании. Так происходит с каждой версией VMware vSphere - старые драйверы убирают, новые добавляют - это нормальный цикл жизни и развития продуктов. Например, больше не поддерживаются следующие процессоры:

• Intel Family 6, Model = 2C (Westmere-EP)
• Intel Family 6, Model = 2F (Westmere-EX)

Однако для тех, кому очень надо, компания VMware оставила небольшую возможность все-таки установить ESXi 7.0 на старом железе со старыми процессорами, но без каких-либо гарантий по работоспособности и поддержке (то есть, статус у этого режима - unsupported). В частности, коллеги написали статью об установке vSphere 7 на сервер IBM M3 X3550 Series.

Для начала решили ставить ESXi на USB-диск, так как RAID-контроллер сервера больше не поддерживается со стороны ESXi 7:

Далее при загрузке установщика ESXi с CD-ROM или ISO нужно нажать комбинацию клавиш Shift + <O> (это буква, а не ноль), после чего появится приглашение ко вводу. Надо ввести вот такую строчку в дополняемую строку:

allowLegacyCPU=true

Далее для установки выбрали USB-диск и начали установку ESXi на него:

После того, как ESXi установится на ваш сервер, вам нужно будет снова нажать Shift + <O> и повторно вбить указанный выше параметр при первом запуске:

Теперь нужно сделать так, чтобы данный параметр добавлялся при каждой загрузке ESXi. Сначала включим сервисы командной строки ESXi и удаленного доступа по SSH. Для этого нужно запустить службы TSM и TSM-SSH на хосте ESXi:

Далее подключаемся к ESXi по SSH и с помощью следующей команды находим файл конфигурации загрузки:

find / -name "boot.cfg

Далее добавляем в него параметр allowLegacyCPU=true в разделе kernelopt:

Два загрузочных модуля ESXi находятся в директориях /bootbank и /altbootbank. На всякий случай надо поменять boot.cfg в обеих директориях.

С помощью команды cat выведите содержимое отредактированных файлов, чтобы убедиться, что параметры загрузки у вас будут сохраняться:

Ну и, собственно, сам сервер ESXi 7.0.0, нормально работающий на сервере IBM x3550 M3:

Бонусом шутка про редактор vi, которым редактировался файл boot.cfg:

Некоторым администраторам может понадобиться PowerCLI-сценарий, с помощью которого можно подсчитать число гостевых операционных систем в виртуальных машинах инфраструктуры VMware vSphere. Stuart в своем блоге рассказал про интересный скрипт, с помощью которого это можно сделать.

Начал он с того, что в переменную $server2012 он записал количество гостевых операционных систем определенного типа с помощью команды:

$server2012 = ((get-vm).extensiondata.guest | Where GuestFullName -eq "Microsoft Windows Server 2012 (64-bit)").count

Далее он стал думать, как сделать таблицу со всеми ОС, для этого решил создать хэш-таблицу, куда будут записываться типы гостевых ОС и их количество:

$OS_hashtable = $null

$OS_hashtable = @{}

$VMs = Get-VM

foreach ($VM in $VMs){
    $OSName = $VM.ExtensionData.Guest.GuestFullName
    If(!($OS_hashtable.ContainsKey($OSName))){
        $OS_hashtable.add($OSName,0)
    }
    $Value = $OS_hashtable.$OSName
    $NewValue = $Value + 1
    $OS_hashtable[$osName] = $NewValue
}
$OS_hashtable | FT -AutoSize

Далее у него получился вот такой результат:

В этой таблице все в порядке, кроме последней строчки - в нее набиваются гостевые ОС, для которых тип не был обнаружен. Поэтому автор добавил следующие строчки с именами ВМ, чтобы добавить значение Unknown таким машинам:

# Added this to the beginning of the script

  $NullOS = Get-Content C:\Scripts\Logs\Guestfullname.txt

# Added this to the foreach loop section

  IF ($OSName -eq $NullOS){$OSName = "Unknown"}

Итоговый скрипт получился таким:

$debug = $false
$OS_hashtable = $null
$OS_hashtable = @{}
$NullOS = Get-Content C:\Scripts\Logs\Guestfullname.txt
$VMs = Get-VM
Foreach ($VM in $VMs){
    $OSName = $VM.ExtensionData.Guest.GuestFullName
    IF ($OSName -eq $NULL){$OSName = $VM.ExtensionData.Config.GuestFullName}
    IF ($OSName -eq $NullOS){$OSName = "Unknown"}
    IF ($debug){write-host "$VM - $OSName"}
    If(!($OS_hashtable.ContainsKey($OSName))){
        $OS_hashtable.add($OSName,0)
    }
    $Value = $OS_hashtable.$OSName
    $NewValue = $Value + 1
    $OS_hashtable[$osName] = $NewValue
}
$OS_hashtable | FT -AutoSize

Как все уже знают, в новой версии платформы виртуализации VMware vSphere 7 средство обновления виртуальной инфраструктуры VMware Update Manager (VUM) уступило место новому продукту - VMware Lifecycle Manager.

Ранее администраторы vSphere использовали VUM для обновлений серверов ESXi и драйверов, а утилиты от производителей серверов - для обновления их микрокода (firmware). Теперь эти процессы объединяются в единый механизм под управлением vSphere Lifecycle Manager.

На сайте buildvirtual.net появился обзор процесса апгрейда хост-серверов ESXi на версию 7.0, который мы приводим ниже, чтобы дать понимание того, что сам процесс, в плане накатывания апгрейда, от VUM почти ничем не отличается.

Итак, сначала надо импортировать ISO-образ в Lifecycle Manager. Запускаем его в vSphere Client и переходим в раздел Imported ISOs:

Нажимаем Import ISO и указываем ISO-образ ESXi 7.0, который скачали с сайта VMware:

После этого данный образ появится в списке:

Затем надо создать бейслайн с этим образом. Нажимаем ссылку New Baseline, где далее указываем тип содержимого Upgrade:

Выбираем образ, который мы хотим привязать к бейслайну:

После этого созданный бейслайн нужно привязать к хостам или кластеру. Для этого выбираем пункт Attach Baseline or Baseline Group:

После успешной привязки к кластеру, жмем кнопку Check Compliance, которая запускает проверку соответствия хостов заданному бейслайну. В итоге мы увидим, например, что 4 хоста находятся в статусе non-compliant, то есть им можно накатить апгрейд (в данном случае - с версии 6.7 на 7.0):

Перед запуском апгрейда нужно выполнить Remediation Pre-Check, чтобы проверить, что в кластере нет препятствий для апгрейда хостов на седьмую версию.

Если ничего критичного не нашлось, жмем на кнопку Remediate:

Это, собственно, запустит сам процесс апгрейда. Вам нужно будет лишь согласиться с EULA и запустить процедуру обновления. После успешного апгрейда будет показано, что все хосты были обновлены:

В консоли вы увидите, что ESXi 7.0 установлен:

То же самое будет и в vSphere Client:

Как видно из описаний шагов, процесс апгрейда с помощью Lifecycle Manager практически ничем не отличается от оного с помощью Update Manager.

Коллеги из Veeam поделились интересной новостью. Во-первых, и это очевидно, что глобальная конференция VeeamON 2020 не будет проводиться в Америке физически, а пройдет онлайн, как и все остальные подобные события. И, во-вторых, что самое приятное - она будет полностью бесплатна для всех.

Дата проведения: 17-18 июня 2020 года. Регистрация по этой ссылке.

Ежегодная конференция VeeamON - одно из крупнейших мероприятий ИТ-отрасли. На VeeamON соберутся ведущие ИТ-эксперты и альянс-партнеры Veeam, такие как VMware, NetApp, Hewlett Packard Enterprise и многие другие.

В рамках двухдневного онлайн-мероприятия компания Veeam расскажет о новой стратегии компании (напомним, она была продана фонду Insight Partners в этом году за 5 миллиардов долларов), покажет все свои самые новые продукты в сфере защиты данных и обеспечения виртуальных датацентров, а также раскроет множество технических деталей, интересных администраторам платформ виртуализации VMware vSphere и Microsoft Hyper-V.

Список главных спикеров конференции:

• William H. Largent - CEO and Chairman of the Board, Veeam Software
• Danny Allan - CTO and Senior Vice President, Product Strategy, Veeam Software
• Jim Kruger - Chief Marketing Officer, Veeam Software
• Anton Gostev - Senior Vice President, Product Management, Veeam Software

Специальный гость - Tripp Crosby, Entertainer & Comedian.

Основные блоки мероприятия:

• Vision and Strategy
• Better Together
• Cloud-Powered
• Architecture and Design
• Implementation Best Practices
• Operations and Support
• Deep Tech

Будет даже онлайн-пати) Присоединяйтесь бесплатно по этой ссылке!

Ну а для тех, кому хочется послушать о самых актуальных новостях Veeam этого года на русском языке, пройдет также бесплатная онлайн-конференция VeeamON Tour 2020.

Дата проведения: 25 июня 2020 года.

Программа конференции:

• 11:00 Вступительное слово. Василий Ваганов, Вице-президент, Северная и Восточная Европа, Ближний Восток, Россия и СНГ
• 11:05 Veeam в 2020: Новости и прогнозы. Владимир Клявин, Региональный Директор, Россия и СНГ, Veeam Software
• 11:25 Пленарная сессия — Технологии. Виталий Савченко, руководитель группы системных инженеров Veeam по России, СНГ, Грузии, Украине и Монголии, Veeam Software
• 11:45 Технические сессии:
  • Лучшие практики и рекомендации для успешной работы с Veeam Agents - Сергей Пискунов, технический консультант Veeam Software
  • Реализация Veeam NAS Backup в версии 10 - Виталий Савченко, руководитель группы системных инженеров Veeam по России, СНГ, Грузии, Украине и Монголии, Veeam Software
• 12:05 Перерыв
• 12:20 Технические сессии:
  • Практические рекомендации по защите данных от программ вымогателей - Павел Косарев, технический консультант Veeam Software
  • Все об интеграции с СХД и новые возможности Veeam v10 - Роман Прытков, технический консультант Veeam Software
• 12:40 Технические сессии:
  • Рекомендации по планированию инфраструктуры Veeam Backup & Replication v10 - Евгений Зосимов, технический консультант Veeam Software
  • Наихудшие практики резервного копирования Office 365 - Никита Козленко, технический консультант Veeam Software
• 13:00 Заключительное слово - Владимир Клявин, Региональный Директор, Россия и СНГ, Veeam Software

Зарегистрироваться бесплатно можно по этой ссылке.

Если вы на своем Mac решили установить VMware ESXi 7 в виртуальной машине на флешке, то с настройками по умолчанию этого сделать не получится - USB-устройство не обнаружится установщиком и не будет видно в разделе настроек USB & Bluetooth виртуальной машины.

Eric Sloof написал, что перед развертыванием ESXi, чтобы установщик увидел USB-диск, нужно перевести USB Compatibility в режим совместимости с USB 3.0:

После этого можно будет выбрать ваш USB-диск для установки ESXi 7.0:

Как вы все знаете, недавно компания VMware сделала доступной для загрузки платформу VMware vSphere 7, где службы управляющего сервера vCenter доступны уже только в формате виртуального модуля vCenter Server Appliance (vCSA).

Блоггер Ozan Orcunus написал интересную заметку о том, как можно отключить автозагрузку некоторых сервисов в vCenter 7. Не секрет, что с каждой новой версией vCenter становится все более и более прожорливым в отношении системных ресурсов. Например, для 10 хостов ESXi и 100 виртуальных машин теперь уже требуется сделать vCSA с двумя vCPU и 12 ГБ оперативной памяти, что слишком много для тестовых окружений, например, на ноутбуке.

Поэтому чтобы vCSA работал немного побыстрее в тестовых средах (и только там, в продакшене этого делать не рекомендуется) можно отключить некоторые его службы при загрузке. В KB 2109881 написано, как останавливать и запускать службы vCenter с помощью команды service-control, но нигде официально не написано о том, как отключать их при старте vCenter.

А делается это следующим образом:

1. Логинимся по SSH на сервер vCSA и переходим в каталог /etc/vmware/vmware-vmon/svcCfgfiles/.

2. Большинство сервисов vCenter - это не стандартные сервисы systemd, а службы спрятанные за за сервисом VMware Service Lifecycle Manager (vmware-vmon). Наберите "systemctl status vmware-vmon" и посмотрите на результат:

Конфигурация сервисов спрятана в JSON-файлах - в директориях, которые можно увидеть в выводе команды. Например, чтобы отключить службу Content Library, нужно открыть файл конфигурации командой:

vi vdcs.json

И выставить в нем параметр StartupType как DISABLED.

3. После внесения всех необходимых изменений нужно перезагрузить vCSA для применения настроек автозапуска.

4. После этого идем в раздел Services и видим, что автозапуск некоторых служб vCenter отключен:

Не все в курсе, но одной из новых возможностей обновленной платформы виртуализации VMware vSphere 7 стала поддержка протокола точной синхронизации времени PTP (Precision Time Protocol) для хост-серверов ESXi и виртуальных машин.

С давних пор для синхронизации времени в виртуальных машинах VMware vSphere использует протокол NTP, который обеспечивает точность синхронизации на уровне миллисекунд. Для большинства систем этого вполне достаточно, но есть и класс систем, где нужна точность на уровне микросекунд при обработке последовательности событий - например, для финансовых приложений, торгующих на бирже, где важен порядок ордеров в стакане.

Abhijeet Deshmukh написал про PTP в vSphere интересную статью, основные моменты которой мы приведем ниже.

Протокол NTP обладает следующими особенностями:

• Имеет точность на уровне единиц миллисекунд.
• Реализуется полностью программно, как для таймстемпинга приема сигналов точного времени, так и для таймстемпинга пользовательского уровня для передачи событий.
• Широко распространен и является индустриальным стандартом синхронизации времени.
• Работает несколько десятилетий, дешев, прост и надежен.
• Клиенты NTP включены во все компьютеры, серверы и роутеры, а также множество программных продуктов.
• Может синхронизировать время от самых разных источников - атомные часы, GPS-ресиверы, а также разные серверы, разбросанные по интернету.
• Клиент-серверная архитектура, позволяющая использовать несколько серверов для синхронизации.
• Возможности коррекции и отказоустойчивости - клиент может забирать время с нескольких серверов и исключать из них тот, который находится географически далеко и отвечает с задержкой сигнала.
• NTP - это юникаст-протокол, который не требует особых правил маршрутизации. Пакеты получает только источник и отправитель.

Для виртуальных машин у NTP есть следующие особенности:

• Сервер ESXi имеет встроенную поддержку NTP на уровне стандарта, а также имеет необходимые компоненты для его поддержки в kernel API.
• NTP работает на порту 123.
• NTP бесшовно работает для клиентов-виртуальных машин, где ОС поддерживают эту интеграцию.
• Как правило проблем с NTP не возникает для гостевых ОС, за исключением некоторых ситуаций, когда, например, вы делаете Suspend виртуальной машины.
• Виртуализация добавляет дополнительные уровни абстракции (например, vNIC), которые потенциально могут повлиять на часы гостевой ОС и переменные синхронизации.

Кстати, о проблеме управления временем в виртуальной инфраструктуре есть отличный документ "Timekeeping in
VMware Virtual Machines". Кроме того, полезно будет прочитать и вот эту статью.

Давайте теперь посмотрим на особенности протокола PTP (IEEE 1588):

• PTP работает на уровне точности в микросекундах, для чего используется механизм Hardware time stamping (это специальные сетевые адаптеры с поддержкой PTP).
• PTP, определенный стандартом IEEE 1588-2008, работает за счет обмена сообщениями мастер-часов и слейв-часов.

Вот так это выглядит:

• Времена отправки и получения событий Sync и Delay_Request сохраняются как 4 таймстемпа T1-T4.
• Сообщения Follow_Up и Delay_Response используются для передачи записанных таймстемпов от мастер-часов к слейв, чтобы осуществить коррекцию времени.
• По окончании передачи слейв-часы имеют все 4 таймстемпа. Это позволяет посчитать смещение от мастера и скорректировать слейв-часы по формуле: Offset = (T2 + T3 – T1 – T4) /2
• PTP в основном используется для обслуживания финансовых транзакций, передачи на уровне телефонных вышек, подводных систем позиционирования и прочих систем реального времени, где требуется высокая точность времени.
• PTP поддерживает отказоустойчивость. Если мастер-часы отказывают, то другой мастер принимает на себя его функции, так как находится в постоянном ожидании. Это реализовано средствами алгоритма Best Master Clock (BMC).
• PTP работает как мультикаст, а значит генерирует дополнительный трафик и требует специальные правила для его перенаправления между сегментами сети.
• Использует 2 UDP-порта - 319 и 320.
• В виртуальной машине для поддержки PTP есть специальное устройство precision clock для получения системного времени хоста.
• В рамках одной сети через PTP все ее виртуальные машины получают точное время.

В итоге можно сделать следующие выводы об использовании протоколов NTP и PTP в виртуальной инфраструктуре:

• Если у вас нет специальных задач под PTP, то старого доброго NTP вполне достаточно. Он надежный и отказоустойчивый.
• Для PTP нужно специальное оборудование, появляется мультикастовый трафик, и требуется изменение сетевых настроек, что вызывает необходимость в дополнительных затратах по настройке инфраструктуры. Очевидно, что развертывать его нужно только в случае появления у приложений в виртуальных машинах требования к точности времени на уровне микросекунд.

Как все уже знают, VMware vSphere 7 вышла, доступна для скачивания и уже обкатывается многими администраторами виртуальных инфраструктур. Для тех, кто еще не знает, поддерживает ли текущее оборудование новый гипервизор ESXi 7, Florian Grehl сделал специальный сценарий PowerCLI, который позволяет вывести эту информацию для серверов кластера:

Сценарий доступен в репозитории на GitHub. Скрипт автоматически загружает функцию HCL-Check (из GitHub), а также JSON-файл для VMware HCL. В переменной $scope можно установить серверы, которые будут проверены (по умолчанию проверяется все окружение vCenter).

Надо понимать, что если ваш хост не поддерживается для VMware ESXi 7, то имеет смысл проверить его еще раз на всякий случай в реальном VMware HCL.

Если вы получаете вот такое сообщение об ошибке:

.\check_esxi_70_support.ps1 : File .\check_esxi_70_support.ps1 cannot be loaded. The file is not digitally signed. You cannot run this script on the current system. For more information about running scripts and setting execution policy, see about_Execution_Policies at http://go.microsoft.com/fwlink/?LinkID=135170.

Значит нужно в свойствах скрипта разблокировать его:

В блоге VMware vSphere появилась интересная запись о том, как происходит работа с памятью в гипервизоре VMware ESXi. Приведем ее основные моменты ниже.

Работа виртуальной машины и ее приложений с памятью (RAM) идет через виртуальную память (Virtual Memory), которая транслируется в физическую память сервера (Physical Memory). Память разбита на страницы - это такие блоки, которыми виртуальная память отображается на физическую. Размер этого блока у разных систем бывает разный, но для ESXi стандартный размер страниц равен 4 КБ, а больших страниц - 2 МБ.

Для трансляции виртуальных адресов в физические используется таблица страниц (Page Table), содержащая записи PTE (Page Table Entries):

Записи PTE хранят в себе ссылки на реальные физические адреса и некоторые параметры страницы памяти (подробнее можно почитать здесь). Структуры записей PTE могут быть разного размера - это WORD (16 bits/2 bytes), DWORD (32 bits/4 bytes) и QWORD (64 bits/8 bytes). Они адресуют большие блоки адресов в физической памяти, к примеру, DWORD адресует блок адресов 4 килобайта (например, адреса от 4096 до 8191).

Память читается и передается гостевой системе и приложениям страницами по 4 КБ или 2 МБ - это позволяет читать содержимое ячеек памяти блоками, что существенно ускоряет быстродействие. Естественно, что при таком подходе есть фрагментация памяти - редко когда требуется записать целое число страниц, и часть памяти остается неиспользуемой. При увеличении размера страницы растет и их фрагментация, но увеличивается быстродействие.

Таблицы страниц (а их может быть несколько) управляются программным или аппаратным компонентом Memory Management Unit (MMU). В случае аппаратного MMU гипервизор передает функции по управлению трансляцией ему, а программный MMU реализован на уровне VMM (Virtual Machine Monitor, часть гипервизора ESXi):

Важный компонент MMU - это буфер ассоциативной трансляции (Translation Lookaside Buffer, TLB), который представляет собой кэш для MMU. TLB всегда находится как минимум в физической памяти, а для процессоров он часто реализован на уровне самого CPU, чтобы обращение к нему было максимально быстрым. Поэтому обычно время доступа к TLB на процессоре составляет около 10 наносекунд, в то время, как доступ к физической памяти составляет примерно 100 наносекунд. VMware vSphere поддерживает Hardware MMU Offload, то есть передачу функций управления памятью на сторону MMU физического процессора.

Итак, если от виртуальной машины появился запрос на доступ к виртуальному адресу 0x00004105, то этот адрес разбивается на адрес виртуальной страницы (Virtual page number - 0x0004) и смещение (Offset - 0x105 - область внутри страницы, к которой идет обращение):

Смещение напрямую передается при доступе к физической странице памяти, а вот тэг виртуальной страницы ищется в TLB. В данном случае в TLB есть запись, что соответствующий этому тэгу адрес физической страницы это 0x0007, соответственно трансляция виртуальной страницы в физическую прошла успешно. Это называется TLB Hit, то есть попадание в кэш.

Возможна и другая ситуация - при декомпозиции виртуального адреса получаемый тэг 0x0003 отсутствует в TLB. В этом случае происходит поиск страницы в физической памяти по тэгу (страницу номер 3) и уже ее адрес транслируется (0x006). Далее запись с этим тэгом добавляется в TLB (при этом старые записи из кэша вытесняются, если он заполнен):

Надо отметить, что такая операция вызывает несколько большую задержку (так как приходится искать в глобальной памяти), и такая ситуация называется TLB Miss, то есть промах TLB.

Но это не самая плохая ситуация, так как счет latency все равно идет на наносекунды. Но доступ может быть и гораздо более долгий (миллисекунды и даже секунды) в том случае, если нужная гостевой ОС страница засвопировалась на диск.

Посмотрим на пример:

Виртуальная машина обратилась к виртуальному адресу 0x00000460, для которого есть тэг 0x0000. В физической памяти для этого тэга выделена страница 0, которая означает, что искать эту страницу нужно на диске, куда страница была сброшена ввиду недостатка физической оперативной памяти.

В этом случае страница восстанавливается с диска в оперативную память (вытесняя самую старую по времени обращения страницу), ну и далее происходит трансляция адреса к этой странице. Эта ситуация называется отказ страницы (Page Fault), что приводит к задержкам в операциях приложения, поэтому иногда полезно отслеживать Page Faults отдельных процессов, чтобы понимать причину падения быстродействия при работе с памятью.